docs: add authentication page covering API keys, access tokens, and o…#63
docs: add authentication page covering API keys, access tokens, and o…#63sweetmantech wants to merge 3 commits intomainfrom
Conversation
…rg access control Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 WalkthroughWalkthroughA new authentication documentation page was added to the Recoup API docs and registered in the Guides navigation under Getting started; it documents API keys, access tokens, authorization flow, and security notes. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
authentication.mdx (1)
35-40: Extract shared API-key cURL example into a snippet.This example duplicates content already present in
quickstart.mdx(Step 3). Centralizing it avoids drift between onboarding pages.As per coding guidelines,
**/*.mdx: “Follow DRY principle - don't duplicate content across pages, use snippets.”🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@authentication.mdx` around lines 35 - 40, Extract the duplicated curl example into a single reusable snippet named "api-key-curl" that contains the curl example with the x-api-key header, then replace the inline code block in both authentication.mdx and quickstart.mdx with an include/reference to that "api-key-curl" snippet so both pages render the same shared content; ensure the snippet name matches exactly and update the import/include statements in authentication.mdx and quickstart.mdx to use that snippet.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@authentication.mdx`:
- Around line 8-14: The current authentication docs imply both API Key and
Bearer tokens are accepted by every endpoint; update authentication.mdx to
clarify that support for "Authorization: Bearer <token>" is endpoint-dependent
rather than global by stating that each operation's security requirements are
defined in api-reference/openapi.json (see operations using apiKeyAuth vs bearer
schemes) and advising integrators to consult that OpenAPI file for which routes
accept bearer tokens versus only x-api-key; include explicit mention of the auth
scheme names (apiKeyAuth and Bearer/Authorization: Bearer) so readers know what
to look for.
- Around line 79-90: The section title "How We Determine Key Type at Creation"
contradicts the copy that states the check happens at authentication time;
rename the title to "How We Determine Key Type at Authentication" and update the
surrounding text to consistently state that the system checks "Has members in
account_organization_ids?" during authentication (not at creation), so that the
decision logic (Organization API Key vs Personal API Key) and the note "this
check happens at authentication time" are aligned and unambiguous.
---
Nitpick comments:
In `@authentication.mdx`:
- Around line 35-40: Extract the duplicated curl example into a single reusable
snippet named "api-key-curl" that contains the curl example with the x-api-key
header, then replace the inline code block in both authentication.mdx and
quickstart.mdx with an include/reference to that "api-key-curl" snippet so both
pages render the same shared content; ensure the snippet name matches exactly
and update the import/include statements in authentication.mdx and
quickstart.mdx to use that snippet.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9fa34e39-1417-4e3e-918e-4c19e51c5345
📒 Files selected for processing (2)
authentication.mdxdocs.json
| ## How We Determine Key Type at Creation | ||
|
|
||
| When a key is created under an account, the API checks whether that account has any organization members: | ||
|
|
||
| ``` | ||
| Has members in account_organization_ids? | ||
| ├── Yes → Organization API Key (orgId = accountId) | ||
| └── No → Personal API Key (orgId = null) | ||
| ``` | ||
|
|
||
| This check happens at **authentication time** (not creation time), so key behavior automatically reflects the current state of the account. | ||
|
|
There was a problem hiding this comment.
Section title contradicts behavior timing.
Line 79 says key type is determined “at Creation,” but Line 89 says the check happens at authentication time. Please align the title and copy so the behavior is unambiguous.
Suggested wording update
-## How We Determine Key Type at Creation
+## How Key Type Is Resolved
@@
-When a key is created under an account, the API checks whether that account has any organization members:
+When a key is used, the API checks whether the owning account currently has any organization members:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## How We Determine Key Type at Creation | |
| When a key is created under an account, the API checks whether that account has any organization members: | |
| ``` | |
| Has members in account_organization_ids? | |
| ├── Yes → Organization API Key (orgId = accountId) | |
| └── No → Personal API Key (orgId = null) | |
| ``` | |
| This check happens at **authentication time** (not creation time), so key behavior automatically reflects the current state of the account. | |
| ## How Key Type Is Resolved | |
| When a key is used, the API checks whether the owning account currently has any organization members: | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@authentication.mdx` around lines 79 - 90, The section title "How We Determine
Key Type at Creation" contradicts the copy that states the check happens at
authentication time; rename the title to "How We Determine Key Type at
Authentication" and update the surrounding text to consistently state that the
system checks "Has members in account_organization_ids?" during authentication
(not at creation), so that the decision logic (Organization API Key vs Personal
API Key) and the note "this check happens at authentication time" are aligned
and unambiguous.
1 participant
…rg access control
Summary by CodeRabbit